Current applications of a Multilayer Path Computation Engine (ML-PCE) in Software Defined Networking (SDN) have a static view of a multi-layer network, and algorithms that calculate routes only focus on finding constraint optimized paths for services provisioned. The real nature of any network however is dynamic and vulnerable to the vagaries of underlying infrastructure, namely the network elements, internal/external links, etc. Network Management Systems (NMS) perform continuous data aggregation that is monitored by system engineers and support groups. The collection of this historical data reveals different facets of the network. Alarms capture a time it was raised, severity, the component that raised it, description, whether it was acknowledged, probable cause, clear time and type of alarm, among other details. Performance Monitoring (PM) data aggregates network traffic observed at regular intervals on each port provisioning a service. In addition, it also gathers information like the collection time, packet loss, oversize or undersize packets received and errors. However, this data is only used to detect problems, like a system component malfunction, crossing of performance threshold, configuration mismatch, signal loss, loss of communication, etc. Conventionally, there is no systematic manner of dynamic feedback that enables the network to automatically alter behavior based on event/PM/alarm data. The historical data on a single element is not analyzed with respect to neighboring connections which might be indicative of a much bigger issue.
Another aspect, in a network topology is the number of services provisioned on the network. For example, services can be Sub-Network Connection (SNCs), Label Switched Paths (LSPs), etc. Details on the services for a network provide information on signal type, source and destination node, its protection class and the ingress/egress ports at each hop. Based on the physical location of Network Elements (NE) and business policies, some have significantly more services than others. In addition, some NEs might be on protection paths for other services. Critical communication or signal loss on NE/components with a lot of services can have a potentially much greater impact than on a relatively less utilized NE.
A Path Computation Engine (PCE) or other path computation component finds routing paths based on a set of constraints in order to efficiently use network resources. PCEs are described in IETF RFCs 4655 and 5440 and HTTP RFCs 7230-7237. The constraints can be defined literally as physical constraints or non-physical constraints; that is, if constraints are placed on Network Elements (NEs), the PCE will calculate a path that includes as few of these constraints as possible for optimal traffic forwarding. Constraints can include physical impediments on transportation mediums, levels of guaranteed bandwidth based on the level of customer buy-in, the importance of the nodes the traffic is forwarded on, etc. Conventionally, network path calculation does not dynamically consider external factors, such as extreme weather, construction projects, etc. into consideration for determining risk assessment on links and other network elements. Network operators must be aware of probable circumstances that could affect their network capabilities and ensure customer satisfaction is satisfactory or better through guarantees of “bandwidth-on-demand” availability and consistent operability of network devices and mediums.
Also, conventionally, Path Computation Element (PCE) outlook is completely resource centric, i.e. it considers NEs and their ports with available links to find reasonable paths. Even if there is an issue indicated by historical alarm/PM or event data, that knowledge is not analyzed or incorporated in path computation. NEs or ports that are already under more stress may end up being part of even more services, which is not desirable. Also in the current setup, once a service is provisioned, the path stays static unless there is a disruption. The network does not proactively suggest an alternate path based on changing network dynamics. Occasionally, business policies that dictate service path or service-level agreements (SLA) change over time. However, currently, that change cannot be automatically reflected in the underlying provisioned service.